ELBのヘルスチェック失敗をCloudWatchアラームで監視してメール通知してみた
こんにちは！コンサル部のinomaso(@inomasosan)です。
ELBのヘルスチェックで失敗した場合にメールを受け取れるように、以下のブログをベースに検証してみました。
今回はAWSマネジメントコンソールでCloudWatchアラーム周りを中心に設定方法まとめました。
ヘルスチェックって何？
ELBからターゲット(EC2等)に対して定期的にヘルスチェックを実行し、正常かどうかを判断することができます。
ヘルスチェックの失敗で、EC2内のWebサービス(ApacheやNGINX)やEC2自体の障害等が発生していることを検知することが可能です。
前提
ALBやEC2等のリソースが作成済みで、平常時のヘルスチェックのステータスがhealthyであることを前提とします。
やってみた
CloudWatchアラームで異常なEC2の数を監視し、アラームが実行された場合はAmazon SNS経由でメール送信するよう設定していきます。
CloudWatchアラーム作成
アラーム作成開始
- AWSマネージメントコンソールから CloudWatch サービスを選択
- 左ペインから
アラーム状態を選択し、アラームの作成をクリック
監視するメトリクスの選択
メトリクスの選択をクリック
参照タブのApplicationELBをクリック
AppELB 別、AZ 別、TG 別メトリクスをクリック
- 監視対象とするELBとターゲットグループのUnHealthyHostCountにチェックを入れ、メトリクスの選択をクリック
- ターゲットグループはEC2等のターゲットの集合体
- UnHealthyHostCountは異常なEC2等の数
メトリクスと条件設定
統計は最小を選択期間は1分を選択- 1分毎にデータを収集
しきい値の種類に静的を選択アラーム条件に以上を選択しきい値に1を入力- 異常なEC2が1台でもあればアラームを実行する
アラームを実行するデータポイントに5/5と入力- 1分毎に収集したデータが5回連続で条件を満たした場合にアラームを実行する
欠落データの処理に欠落データを不正 (しきい値を超えている)として処理を選択- EC2自体が停止している場合はデータ自体が取得できないので、アラームを実行するには、しきい値を超えた扱いにする必要がある
通知設定
アラーム状態トリガーにアラーム状態を選択次の SNS トピックに通知を送信に新しいトピックの作成をチェック新規トピック名に一意となる任意の名前を入力通知を受け取る E メールエンドポイントにメール受け取り可能なメールアドレスを入力- 上記が全て完了したら
トピックの作成をクリック
- SNSトピックが作成されたことを確認
トピックの作成をクリック後に以下のような画面が表示されること
アラームの名前
アラーム名に任意の名前を入力
プレビューと作成
- ここまで入力した内容が表示されるので、問題ないことを確認し
アラームの作成をクリック
Amazon SNSサブスクリプション
Amazon SNS経由でCloudWatchアラームのメールを受信するためには、設定したメールアドレスに届いたメールから登録完了する必要があります。
ただし、メールのConfirm subscriptionリンクをクリックして有効化すると、日々の運用でAmazon SNS経由のメールに記載されている登録解除用のリンクによる登録解除の危険性があります。
以下のブログにリンクを押しても登録解除されないやり方が記載されていますので、そちらを参考に作業願います。
アラームテスト
UnHealthyHostCountを1以上にする
今回は手っ取り早くテストするために、ヘルスチェックのパスを存在しないパスに変更してテストしてみます。
しばらく待つとCloudWatchアラームの状態がアラーム状態となり、以下のようなメールが送信されてきます。
Reason for State Changeを見ると、5回連続でしきい値を超えたためにALARMになったことがわかりますね。
欠落データを発生させる
上述したとおり、EC2自体が停止した場合は、UnHealthyHostCountはデータ自体が取得できません。 なので、今回のテストではEC2自体を停止させて、アラームが実行されるか確認してみます。
しばらく待つと、UnHealthyHostCountを1以上にした時と同様の状態となります。
Reason for State Changeは先ほどと異なり、データ自体が存在しないことが原因とわかります。
まとめ
ELBのヘルスチェック結果の監視は簡単そうに見えて、欠落データを気にしないといけないなど気にしなきゃいけないポイントがあって勉強になりました。
今回はUnHealthyHostCountのみを監視対象としましたが、ターゲットグループ毎に複数台のEC2を運用する場合はHealthyHostCountも組み合わせてシステムの特性にあった監視を検討するのが良いかと思います。
この記事が、どなたかのお役に立てば幸いです。それでは！
